<Project Name>

Development Case

Version <1.0>

[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document.

Important: There are hyperlinks to pages in the RUP in this template. These hyperlinks must be modified when you create your own development case. For example, assume that the Rational Unified Process is installed in a folder named 'RationalUnifiedProcessX.X'. Also assume that you put the development case at the same level as the Rational Unified Process. In that case you should: 
   Search: "../../../"
   Replace: "RationalUnifiedProcessX.X"]

Revision History

Table of Contents

• Introduction
  • Purpose
  • Scope
  • Definitions, Acronyms and Abbreviations
  • References
  • Overview
• Overview of the Development Case
  • Lifecycle Model
  • Core Workflows
  • Core Workflow Configuration
  • Artifact Classification
  • Review Procedures
  • Sample Iteration Plans
• Core Workflows
  • Business Modeling
  • Requirements
  • Analysis & Design
  • Implementation
  • Testing
  • Deployment
  • Configuration & Change Management
  • Project Management
  • Environment
• Workers

Introduction (to top)

Purpose (to top)

[A brief description of the purpose of the Development Case, for example:

"The purpose of the document is to describe the development process for the <<project name>>."

Also give a brief description of what the Development Case applies to; what is affected or influenced by this document.]

Scope (to top)

[A brief description of the scope of this Development Case; what Project(s) it is associated with, and anything else that is affected or influenced by this document.]

Definitions, Acronyms and Abbreviations (to top)

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Development Case. This information may be provided by reference to the project Glossary.]

References (to top)

[This subsection should provide a complete list of all documents referenced elsewhere in the Development Case. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

Overview (to top)

[This subsection should briefly describe what the rest of the Development Case contains and explain how the document is organized.]

Overview of the Development Case (to top)

Lifecycle Model (to top)

[Briefly describe the lifecycle model employed by the project; containing descriptions of the milestones and their purpose. The purpose is to serve as an introduction to the rest of the development case, not to be a project plan.]

Core Workflows (to top)

[Describe which workflows the development case covers.]

Core Workflow Configuration  (to top)

[Explain how the workflow configuration works. Explain the sections in the Core Workflow sections. Use the following text as a starting point:]

The purpose of this section is to explain how the core workflow configuration works. This includes the purpose of the different tables and sections that describe each core workflow, in section "Core Workflows".

Section: "Workflow"

This section should detail any changes made to the structure of the workflow itself. Typical changes are the addition of activities to describe company specific ways of working, or the removal of activities from the workflow.

Section: "Artifacts"

The section describes, in a table, how the artifact will be used. Additional 'local' artifacts can be added to the table as needed. 

Section: "Notes on Artifacts"

This section has three main purposes: 

• It contains a list all artifacts that you 'Won't' use, and the motives to why you have decided to not use them. 
• It contains a reference to the project's Configuration Management Plan, which describes the configuration management strategy to be used when working on these artifacts. The CM Plan should allow developers to answer questions such as: 
  • When do I release my artifact? 
  • Where do I put my newly created or modified artifact?
  • Where do I find existing artifacts for the project?
• If the development case is a an organization-level development case, this is the place where you add notes on what each project should think about when they decide what to do with the artifact. Use the predefined table below, as a starting point. 

Section: "Reports"

The section lists the reports to be used. Additional 'local' reports can be added to the table as needed.

Section: "Notes on the Reports"

This section has two main purposes. First, it will list all reports that the project decided that it 'Won't' use, and motive why it was decided to not use them. Secondly, if the development case is a an organization-level use case, this is the place to add notes on what each project should think about when they decide what to do with the report.

Section: "Additional Review Procedures"

This section captures any additional review procedures that are required for the artifacts used in the workflow. These supplement the general review procedures described in the Overview section, of the Development Case.

Section: "Other Issues"

This section captures any outstanding issues with the workflow's configuration. This section can be used as an issues list whilst the development case is being built.

Section: "Configuring the Workflow"

[This section is used if the development case is a an organization-level development case. This section contains references to helpful information for use when configuring the workflow. This section can be removed by a project.] 

Artifact Classification (to top)

[Introduce the artifacts and the classification scheme. Use the following text as a starting point:]

An artifact is a deliverable of the process. It is often developed within one core workflow, though there are exceptions. The artifacts are organized in the workflow where it is created. To describe how an artifact should be used, we use the following classification scheme (see Guidelines: Classifying Artifacts for details):  

• Must

• Should

• Could

• Won't

Review Procedures (to top)

[Introduce the review levels and any additional review procedures. Use the following text as a starting point:]

• Formal-External
• Formal-Internal
• Informal
• None

For details see Guidelines: Review Levels.

Sample Iteration Plans  (to top)

Inception Phase

[List the sample iteration plans used during Inception.]

Elaboration Phase

[List the sample iteration plans used during Elaboration.]

Construction Phase

[List the sample iteration plans used during Construction.]

Transition Phase

[List the sample iteration plans used during Transition.]

Core Workflows (to top)

Business Modeling (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Requirements (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Analysis & Design (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Implementation (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Testing (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Deployment (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Configuration & Change Management (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Project Management (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Environment (to top)

[See the section Core Workflow Configuration that describes what each of the following sections should contain.]

Workflow

Artifacts

Notes on the Artifacts

Reports

Notes on the Reports

Additional Review Procedures

Other Issues

Configuring the Workflow

Workers (to top)

[This section is used for the following purposes:

• To describe any changes in the set of workers. For example, it is common that you refine the worker Stakeholder into more than one worker. 

• To map job positions in the organization to the workers in the Rational Unified Process. The reason for this is that in some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the workers in the Rational Unified Process, and the job positions in the organization. Mapping job positions to workers can make it easier for people in the organization understand how to employ the Rational Unified Process. The mapping can also help people understand that workers are not job positions, which is a common misconception. ]

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process